Increases in the use of computers throughout many differing environments has led to a wide range of computer users with differing levels of computer knowledge operating computers. Users ranging from, for example, the occasional home user to the dedicated software developer, may each have differing expectations for system performance as well as differing levels of complexity in an application program which may cause intimidation and, thus, a reluctance to use a product.
In an effort to reduce the complexity of applications and present a more “user friendly” computing environment, graphic user interfaces (GUIs) have been developed. GUIs are believed to present an easier to understand interface to an application's users and, thus, reduce the intimidation of an application. GUIs typically include multiple windows in which information is presented and user input obtained. Each of these windows may interact with one or more applications and may share data with one or more applications or other windows. However, development of these multiple window interfaces may be complex as interactions between the windows may be limited by the underlying application or by particular sequences of events which may be dictated by the windows.
A further complication in modern computing environments may be added in a network environment where multiple users share data across a computer network. Such an environment may provide convenience in that it allows a central repository of data but may add further complications in managing this data as multiple users may desire to access such data simultaneously or concurrently. Thus, applications and, in particular, user interfaces for applications may have increased complexity associated with them to manage the interaction of users with a shared network resource, such as a database, to coordinate users' interactions with the shared resource.
Efforts to reduce the complexity of developing applications in such complex environments have included International Business Machines, Inc.'s (IBM) VisualAge™ programming tools. This “visual” programming language takes advantage of object-oriented programming to provide programmers with program objects which may be visually manipulated to provide an application or portion of an application such as a user interface. Thus, a user may graphically represent an application or user interface as a collection of objects and then graphically define the interaction between the objects in the application or portion of the application.
While the visual programming languages may reduce the complexity of developing programs, further refinements in the management of objects may be needed to further simplify the complexities of multiple windows or multiple users. For example, to assure data integrity of shared data, conventionally systems have utilized a “transaction” paradigm which provides for isolation between transactions. A transaction represents a logical group of changes or operations associated with one or more objects that will be performed in an atomic manner (that is, either all operations within the transaction are performed, or none of them are performed). For example, the two-phase commit procedures associated with databases would be considered a transaction based paradigm. Imposition of a transaction based paradigm may allow for more orderly handling of multiple users with shared resources or multiple applications or portions of applications with shared resources (e.g. multiple windows in a user interface) by allowing isolation of transactions from each other such that the consequences of any single transaction on other transactions may be predicted and/or controlled via the commit procedure of the transaction. One method of isolation is provided by each transaction maintaining its own independent copy or version of all data or objects associated with the transaction until a commit is performed. At the commit time the versions are reconciled with the shared resource and the resource is either updated or the commit is rejected and the resource remains unchanged.
However, even in transaction based environments difficulties may arise where multiple transactions result in anomalous or undesirable results. For example, in the user interface example, if each window is treated as a transaction, then if a user is allowed to switch between different windows, multiple concurrent transactions may result. Similarly, if each user of multiple users of a shared resource is treated as a transaction, then multiple users concurrently accessing the resource may result in multiple concurrent transactions. However, if each of the multiple concurrent transactions utilize variables which are based on the same objects, then changes in one transaction to the variable may change the underlying object thereby effectively eliminating isolation between transactions. Several different approaches to provide solutions to such situations have been proposed, however, each of these solutions has its own limitations.
One proposed solution would be to provide only a single window such that only a single transaction is allowed. Thus, interactions difficulties between multiple transactions are avoided by not allowing multiple transactions. However, such a solution reduces the ability of graphic user interfaces to simplify the interface through the use of multiple windows. Furthermore, in the shared network resource environment such a solution would be impractical as it would mean that only a single user could utilize the shared resources at any given time.
One further approach is to make transactions “modal” in that each transaction must be completed before other transactions may be performed. However, such an approach may be restrictive in that the sequence of transactions may be artificially imposed on a user and, therefore, may not suit the users particular situation. For example, in a user interface if a dialog window is modal then its transaction must be completed before any other transaction (i.e. window) may be accessed. However, often users wish to switch between windows, for example when entering data, and do not wish to complete a transaction before switching to another window (i.e. another transaction). Such a modal system would require the user to enter the data and complete the data entry transaction before switching to another window which may result in prematurely committing data. It may then be difficult to “roll back” the committed data. Otherwise, the transaction associated with a window may cache the underlying data in its own variables, however, such a solution would not utilize the underlying domain objects and, therefore, would be less object oriented.
Another approach which may solve the above problem with modal transactions is to switch between transactions as dialog windows gain or lose focus. Thus, when a user selects another window the new window would have focus and the active transaction would switch to the transaction associated with the new window. However, such a system may result in errors resulting from the lack of control over the order in which transactions go in and out of focus or subtle differences in the way operating systems treat dialogs going in and out of focus. Furthermore, activity that is transaction sensitive may occur in a background dialog (such as a window without focus). For example, a domain model could be calling back to a user interface via a dependency mechanism in an attempt to have the user interface refresh the displayed values. If the dialog does not have focus and the transaction switching has not occurred, then the incorrect values may be retrieved.
In light of the above discussion, a need exists for improvement in the handling the interaction of transactions.